1. Field of the Invention
The present invention relates to a task switching technique involved in a real time operating system (RTOS).
2. Related Art
In an electronic control unit (ECU) installed on a vehicle, some processes included in its control program should be executed in real time for providing the sufficient responsiveness of control and a driver's safety. Accordingly, the control program is composed of tasks to each of which a priority level is assigned, and a RTOS performs switching among the tasks during execution of the control program so that processes of a higher priority are executed in real time.
Specifically, when occurrence of an event is detected, an activation request program requests activation of a task which includes a process (event process) corresponding to the event. The RTOS activates the task in response to the request, and the activated task executes the event process. A priority level is assigned to each of the tasks as described above based on the priority of execution. A process that is strongly required to be executed in real time is included in a higher priority task. When activation of a task, which is not active, is requested, the RTOS activates the task if the priority level of the task is higher than the priority level of an active task.
A task switching technique that creates tasks corresponding to the respective priority levels is proposed. In this case, all the event processes of the same priority level are included in the task corresponding to the priority level as follows.
Assuming that one of three priority levels is assigned to each of the tasks, a higher priority task A, a moderate priority task B, and a lower priority task C are created as shown in FIG. 5. A 1 ms process, a 30° CA (crank angle) process and the like are included in the task A. The 1 ms process is executed every 1 ms, and the 30° CA process is executed for every 30° rotation of the crankshaft.
A 4 ms process, an 8 ms process, a Tdc process, an engine stall process, a fault detection process and the like are included in the task B. The 4 ms process is executed every 4 ms, and the 8 ms process is executed every 8 ms. The Tdc process is executed whenever the piston of a specific cylinder reaches the top dead center (TDC). The engine stall process is executed when the engine of the vehicle stalls. The fault detection process is executed for detecting a fault for self-diagnosis. A 16 ms process, a 32 ms process and the like are included in the task C. The 16 ms process is executed every 16 ms, and the 32 ms process is executed every 32 ms.
This task switching technique thus creates the tasks corresponding to the respective priority levels, because the RTOS performs switching among the tasks based on the priority levels of the tasks. According to this technique, the number of the tasks equals the number of the priority levels, that is, it is not very large. Further the amount of management information which should be held by the RTOS is relatively small, and consequently the capacity of memory such as RAM required for storing the management information is also relatively low.
However, according to the technique, each of the tasks should select the event process to be executed from the event processes included therein.
Specifically, in response to occurrence of an event, the activation request program requests the RTOS to activate the task which includes the event process corresponding to the event and simultaneously stores identification (ID) information on the event process in a queue (storage area). When the RTOS activates the task, the activated task retrieves the ID of the event process to be executed from the queue and executes the event process corresponding to the retrieved ID.
A FIFO (first-in first-out) queue, which is a buffer from which the IDs are retrieved in the same order they were stored, is employed for storing the IDs of the event processes in consideration of the case that various events occur in quick succession.
According to the above technique, whenever an event occurs, the ID of the corresponding event process should be stored in the queue and retrieved from the queue, that is, a queuing operation should be executed. Further, it should be determined for queuing whether at least one ID is stored in the queue and whether the queue is full. Therefore the CPU load is heavy when the various events occur in quick succession.
When the CPU load is heavy, activation of a task of a lower priority is delayed, and consequently execution of the event process included in the lower priority task is delayed. When the CPU load reaches the limit of CPU capability, the event process included in the lower priority task is discarded, that is, it is not executed in the end. As a result, the responsiveness of control is lowered, and consequently the performance of the ECU is degraded.